Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Containing parts may embed other parts, or rather they may embed frames which display other parts. There are several situations that may cause a containing part to embed another part:
• data was dragged or pasted into the containing part, and the options on the operation indicated the data should be embedded as a part.
• a part was inserted into the containing part using the “Insert…” menu command.
• a content operation within the containing part caused it to embed another part.
• an embedded part asked the containing part for another frame, possibly for a continuation or alternate view of the same part.
In the first three cases, the containing part itself initiates the actual embedding in response to some other action. In the last case, the embedded part initiates the embedding by calling containingPart->RequestEmbeddedFrame().
In any case, the containing part creates a frame in which to embed a part by asking the draft to create one:
newFrame = draft->CreateFrame(ev,
kODFrameObject,
containingFrame,
newShape,
biasCanvas,
embeddedPart,
viewType,
presentation,
kODFalse, // isRoot must be false
isOverlaid);
The new frame returned from ODDraft::CreateFrame() has already been initialized. The frame also made itself a display frame of the embeddedPart by calling
embeddedPart->DisplayFrameAdded(ev, somSelf);
This ensures that the new frame can be used as soon as it is returned by the draft. For more about what may have happened during DisplayFrameAdded(), see the recipe for Adding a Display Frame.
Once the new frame is returned, the containing part must store it somewhere in its content. How the part stores its content internally is up to the developer. If the new frame is visible within the containing frame, the containing part must create a facet for it. See the recipe for Making a Frame Visible.
Note that if the embedded part tries to negotiate a different frame shape during its DispalyFrameAdded call, the containing part will get the RequestFrameShape call before the CreateFrame call returns. If the containing part is not multi-threaded, it will not be too difficult to handle the request; the containing part must just be able to do the negotiation without having an actual frame present in its contents. If the part is multi-threaded, there could be several CreateFrame requests pending simultaneously. In that case, the containing part must be able to disambiguate the embedded frames. Testing for object equality of the frameShape and the newShape parameter is probably a good way to do it, as the shape cannot be shared between different frames.
